I would say that the file should contain all the information in the repo that is also stored by git, i.e. the information we need to sync back and forth. Is that correct?

What I meant to do here is to contrast information like the contents of commits -- for which the git repo is authoritative and the only place they are stored -- and the "last seen" git state (which not literally stored by git, as it is different from the current git state)

I'm thinking about how to clarify this comment. Perhaps we should say something about storing information that can be potentially conflicted between jj and git. That's what makes it necessary to sync it back and forth, as you said.

Maybe something like this:

Conceptually, this state should contain all the information in the
repo that can be updated by either git or jj. For example, branches should
be stored here, but remote-tracking branches and other git refs should not.

Actually, what problem does "It is currently affected by undo, which can cause minor issues." refer to?

what problem does "It is currently affected by undo, which can cause minor issues." refer to?

Mainly, jj undo after jj git fetch/push can move remote tracking branches. If we use the remote tracking branches for --force-with-lease, it could become a bigger problem.

An example that I mean to turn into a test (unless I already have):

jj git push --branch a
jj branch s a -r somewhere
jj git push --branch a
jj op restore @--

At this point, another jj git push --branch a should push the branch a, but I think it won't because it will consider the branch unchanged.

At this point, another jj git push --branch a should push the branch a, but I think it won't because it will consider the branch unchanged.

IIRC, git push doesn't check the 'local' value of the remote branch (refs/remotes/my-remote/my-branch on the local clone); it only checks the 'remote' value of the remote branch (refs/heads/my-branch on the remote). So if jj git push replicates git push closely (that depends on libgit2 and whether we added extra steps), it should push the branch.

Ah sorry, I forgot about the --force-with-lease argument, in which case, the 'local' value is checked, yes. I agree that that would be confusing.

I see this file as a way of detecting what has changed in git since last time. I suppose you can think of it much like a merge base used when merging git's current state with jj's current state. So we would still need to store the current state in the view, I think.

I think we can consider removing the git_refs we track, but that's a separate question of cost/benefit (do users care enough about seeing them in log output?). I don't want to remove the tracking of remote branches in general, especially since that's not specific to the git backend, so we can't rely on git's state.

Do you think we need to track remote-tracking branches too? Since they can't be modified directly (only via import and undo/restore), I feel like we shouldn't track them and instead consider the Git repo the source of truth.

This became a confusing question for me once I started thinking about the issue of concurrency and distributed filesystems, where we can't really trust git. Ignoring those questions, you are probably right.

However, if a repo is on Dropbox and the remote-tracking branch in git gets corrupted, the current behavior of creating a conflict is nice. Or should we just lose the remote tracking branch position in that case? This becomes more important when we try to do something like --force-with-lease.

I'm also not sure if the same answer is good for colocated and non-colocated repositories.

Also, what you said here seems to contradict what you said in #1487 (comment). Does this mean you are in the same uncertain position I am, or did I misunderstand your point?

I agree that this is confusing, but I don't see the contradiction between these two comments. I think both are saying that we should store our own concept of remote-tracking branches in the view object but probably not in the new file introduced by this PR.

if a repo is on Dropbox and the remote-tracking branch in git gets corrupted, the current behavior of creating a conflict is nice

Yes, I agree. Ah, it was probably my "Do you think we need to track remote-tracking branches too?" that sounded like I was saying that we shouldn't even track them in our model? I meant it in the context of the new file introduced by this PR, i.e. that I don't think we need to track remote-tracking branches in that file.

Makes sense?

sounded like I was saying that we shouldn't even track them in our model?

Yes, that's what I was thinking about.

I don't think we need to track remote-tracking branches in that file. Makes sense?

I think it makes sense in practice; that's what the reality would be after this PR. I'm not 100% sure it works in theory :). In other words, it makes sense in the short term, and I'm still confused about the long term.

Mostly, that's because I was hoping that we could have a framework where exported branches and remote-tracking branches are treated in the same way. That may simply be a flawed idea, but I haven't adjusted my mind to a consistent theory of how it should work otherwise. I guess we forget jj's view of remote tracking branches whenever there is a conflict or git loses this information and wait for the next fetch. Hopefully this will work OK for our version of --force-with-lease.

I guess what I'm saying in the last paragraph is that I'm not sure there's a behavior that keeps the remote-tracking branches in jj's model, makes sense, doesn't track the conflict base for conflits between jj and git, works with undo (or can we compromise here?), and generates benefit compared to only tracking them in git. I'm also not sure it doesn't exist. Finally, I'm additionally not sure how the current jj behavior measures up on the last two points.